Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
RYU SDN Crash Course - Book
KNET Solutions (Online Training Centre),
Phone/WhatsApp: +919445042007
Academic SDN Mini Project Training.
1. Introduction
This Book is (RYU SDN CRASH COURSE Course book), prepared by KNET Solutions. This Book is used as Course material for UDEMY SDN Crash Course.
The Course is available in 
. The Course link is UDEMY SDN CRASH COURSE
This Course covers SDN Basics, OpenFlow Theory, Mininet Basics, Mininet Programming, RYU Controller Basics, RYU Controller built-in applications, RYU Controller Programming, Writing your own sdn application in RYU Controller, Multicontroller environments etc.
Some book contents (IMAGE/Text) are copied from Freely available resources from internet / RFCs/ Opensource materials. Thanks to the original authors.
This Book is free to use.
Diarmuid O'Briain made an extensive RYU Tutorials, RYU Tutorial
2. SDN Overview
SDN Introduction
SDN suggests to centralize network intelligence in one network component by disassociating the forwarding process of network packets (data plane) from the routing process (control plane). The control plane consists of one or more controllers which are considered as the brain of SDN network where the whole intelligence is incorporated.
Enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services. The OpenFlow protocol is a foundational element for building SDN solutions.
SDN Architecutre
SDN architectures generally have three components or groups of functionality:
The SDN networking devices control the forwarding and data processing capabilities for the network. This includes forwarding and processing of the data path. Example: Openvswitch (openflow protocol)
SouthBound Interface:
Southbound interface is the connection between the controller and the physically networking hardware
SDN Controller
The SDN Controller is a logical entity that receives instructions or requirements from the SDN Application layer and relays them to the networking components. The controller also extracts information about the network from the hardware devices and communicates back to the SDN Applications with an abstract view of the network, including statistics and events about what is happening.
Example:
RYU, OpenDayLight, ONOS, FloodLight etc
SDN Applications:
SDN Applications are programs that communicate behaviors and needed resources with the SDN Controller via application programming interface (APIs). These applications could include networking management, analytics, or business applications used to run large data centers. This is the place for research, innovations, new ideas etc.
A Northbound interface is defined as the connection between the controller and applications.
3. SDN Test bed Installation
Setup the SDN Test environment to practice Openflow usecases with RYU SDN Controller.
There are two option.
Download the prebuilt SDN Test bed VM image(ubuntu 20.04 desktop) and use it
Setup the SDN Test bed by your self(Fresh Installation on ubuntu 20.04)
Option1: Prebuilt VM Image
This is the easiest option(for new comer).
Prebuilt VM Image (OVA Format), Size 3.3GB can be download from this below link,
https://drive.google.com/file/d/1_eC9O6EW7fh5YUp_LJMQ3_gIyFXBIc8k/view?usp=sharing
username : test password : test
This can be imported in Oracle VirtualBox. Just double click the OVA file it will be imported automatically.
- Follow this youtube video https://youtu.be/93lM4OLyytE
- https://docs.oracle.com/cd/E26217_01/E26796/html/qs-import-vm.html
This should be imported in VMWARE also.
Option2: Fresh Installation
If you want to setup the testbed by yourself follow this
Requirements:
OS: Ubuntu 20.04
CPU: 2 Cores +
RAM: 4GB +
HDD: 15GB+
If you are using Windows or other OS, you can install Ubuntu 20.04 as a Virtual Machine(VM) using Virtual Box .
You can download the ISO installer from the below link,
https://www.ubuntu.com/download/desktop
Please run the below commands in UBUNTU Terminal
To check the python version:
python3 --version or python --version
To verify :
ovs-vsctl --version
Testing
Open 4 Terminals:
- In Terminal1,
And start the capture for "loopback" or "any" interface.
- In Terminal2,
- In Terminal3,
you will get the mininet prompt. In mininet prompt, type pingall comamnd
pingall
Logs:
- In Terminal 4,
sudo ovs-vsctl show
sudo ovs-ofctl -O OpenFlow13 dump-flows s1
Logs:
- check the openflow messages in wireshark
Stop the Wireshark capture,
In the filter type "openflow_v4" to see the OPENFLOW Messages.
4. Networking Concepts
TCP/IP Layers
Network Packet Capture & Protocol Analyzer
Wireshark
- Traffic Capture & Network protocol analyzer
- GUI
- Capture the Traffic from the interface
- Open the capture file and analyze it
Ethernet (Layer2) Concepts
- Ethernet is Layer2 Protocol,
- Majorly used as LAN connectivity
- Interface (eth0, eth1, ….)
- MAC Address is L2 Address, Associated with the interface, its 8 bytes (HWaddr 02:42:ac:11:00:02)
Ethernet Frame
Neighbour Discovery
The MAC address is how machines on a subnet communicate. When machine A sends packets to another machine on its subnet, it sends it using the MAC address. When sending a packet to a machine on the public Internet, the packet is sent to the MAC address of the router interface that is the default gateway. IP addresses are used to figure out the MAC address to send to using ARP.
ARP Basics
ARP stands for Address Resolution Protocol. When you try to ping an IP address on your local network, say 192.168.1.1, your system has to turn the IP address 192.168.1.1 into a MAC address. This involves using ARP to resolve the address, hence its name.
Systems keep an ARP look-up table where they store information about what IP addresses are associated with what MAC addresses.
When trying to send a packet to an IP address, the system will first consult this table to see if it already knows the MAC address. If there is a value cached, ARP is not used.
If the IP address is not found in the ARP table, the system will then send a broadcast packet to the network using the ARP protocol to ask "who has 192.168.1.1".
Because it is a broadcast packet, it is sent to a special MAC address that causes all machines on the network to receive it.
Any machine with the requested IP address will reply with an ARP packet that says "I am 192.168.1.1", and this includes the MAC address which can receive packets for that IP.
ARP Table
List ARP Table
Delete ARP entry
ARP Demo
Start the mininet topology (linear topology , not connected to SDN Controller)
sudo python traditional_switch.py
in mininet console, run 'links' command to identify the link names
mininet> linksh1-eth0<->s1-eth1 (OK OK)h2-eth0<->s1-eth2 (OK OK)h3-eth0<->s1-eth3 (OK OK)h4-eth0<->s1-eth4 (OK OK)mininet>So if we want to capture wireshark traces for h2, we have to capture the s1-eth2 interface.
capture wireshark traces for h2
in mininet console run 'h1 ping h2'
Analyze the ARP Packets from Wireshark traces
check the ARP entries in h1 and h2
mininet>h1 arp -a
Traditional L2 Switch
A network switch (MAC bridge) is a computer networking device that connects devices together on a computer network by using packet switching to receive, process, and forward data to the destination device.
Control Plane
Learns the MAC Address from the incoming packet and populate the MAC Table
Data Plane
- Receives the Packet
- Read the Destination MAC from the Packet
- Look up the MAC Table for the destination Port
- Forward the Packet to the destination Port
Openvswitch is softswitch, which works as normal switch(traditional) as well as SDN(openflow)switch
Demo
Same steps as Neighbour discovery Demo
Lets run OVS commands to check the switch
How it works
- Traditional Switch have built in Control Plane + Data Plane.
- Mac Table( a.k.a Forwarding table) is Empty when the switch starts.
- Control Plane updates the Mac Table with the MAC and the PORT Number. This information is extracted from incoming Packet.
- Control Plane keeps on building/updating the Mac Table.
- When the packet arrives, Switch Data plane looks the Mac table, if the destination MAC matches in the Mac table, it forwards the packet to the respective Port.
SDN Switch(Openflow Switch)
- Run the Linear Mininet Topology,
Start Wireshark Capture
RYU L3 Application
- In the mininet cli, ping h1 to h2.
- Check the OpenFlow flows
How it works
- Switch is configured with SDN Controller IP and Openflow protocol version.
- Switch establishes the communication with SDN Controller.
- SDN Controller installs the default Openflow rule (TABLE MISS ENTRY) in the switch Flow table.
- TABLE MISS Entry openflow rule matches with all the packets and send it to the CONTROLLER. The priority is lowest in the table(0)
- When the Host Data Packet arrives in the Switch, It will be matched with TABLE MISS ENTRY , and the packet will be sent it to Controller ( PACKET IN Message)
- Controller receives the packet, and build the Switch Logic with the packets.
- Controller adds the OPENFLOW flows to the switch.
- Now, Switch data path is built with flows. So next time, when the Packet arrives it will be matched with the Flow table and forward the packet to respective port.
5. Mininet
Basic Operations
1. To check the mininet version
2. To clean up the existing ovs bridges and namespaces
Note: sometime we mistakenly closed the mininet shell, or mininet crashed. But the topology components will continue to exists. To clean such stuff, cleanup command is used.
3. Our First Topology (Single)
Topology with Single Switch and 4 Nodes.
RYU SDN Controller
Mininet Topology
| options | Description |
|---|---|
| --controller | type of controller local/remote and remote controller ip. |
| --mac | mac address starts with 00:00:00:00:00:01 |
| -i | IP Subnets for the Topology |
| --switch | Switch type (ovsk - openvswitch kernel module), and openflow version. |
| --topo | topology type(linear,minimal,reversed,single,torus,tree) and params. |
Once you are done, make sure "exit" the mininet shell,
exit
Example:
4. Mininet Basic Shell Commands
Informative commands
Action commands
Execute the commands in HOST/Node:
Option1:
we can login to each host using 'xterm' command
xterm h1
It will open a xterm terminal for the host. Now we can execute the command inside that terminal
Option2:
we can directly execute from the mininet shell.
Example:
we can use either method to run the Traffic tests or executing the commands.
5. Linear Topology
linear topology (where each switch has one host, and all switches connect in a line)
6. Tree Topology
fanout : each switch is connected to these many childs depth : depth of the tree
Running Traffic Tests
- TCP/UDP Traffic Tests
a. Setup the Topology with xterms options (open terminal for each Node)
b. TCP Traffic Test between h1 to h4
Run IPERF TCP Server in h4
-s means server mode
RUN IPERF TCP Client in h1
-c means client mode.
-i means reporting interval
-t means test duration in seconds
-b means bandwidth 10m means 10Mbps
-P means parallel connections
c. UDP Traffic Test between h1 to h4
Run IPERF UDP Server in h4
-u means udp
RUN IPERF UDP Client in h1
-b means bandwidth 10m means 10Mbps
HTTP Traffic Tests
Run Python Simple Web Server in h4
From H1, Access the Web server
curl utility used as web client to access the web server.
If we want to simulate the 1000s users accessing the web server on the same time (load), we can use ab(apache bench) tool
-c 50 means parallel request per second (50 Requests per second)
-n 500 means total request for this test (500 requests)
Apache bench tool have lot more options , More details can be found from the below link
https://httpd.apache.org/docs/2.4/programs/ab.html
Writing Custom Topology in Mininet
mininet exposes the python API. We can create a custom topologies using the python API with few lines of code.
How to write Custom Topology in Mininet
Steps are below.
Import the python required libraries
from mininet.topo import Topofrom mininet.net import MininetWrite the Topology definition class
class SingleSwitchTopo(Topo):def build(self):s1 = self.addSwitch('s1')h1 = self.addHost('h1')h2 = self.addHost('h2')h3 = self.addHost('h3')h4 = self.addHost('h4')self.addLink(h1, s1)self.addLink(h2, s1)self.addLink(h3, s1)self.addLink(h4, s1)
Important Topology definition APIs:
- Run the Topology as below,
- Create the Topology object
- Create the Mininet with Topology object
- Start the Mininet
How to run
- start the RYU SDN Controller
- Run the Mininet topology file
- Perform your tests/operation etc.
6. Openflow Theory
This document text/diagram is copied from the Openflow 1.3 specifications
https://www.opennetworking.org/software-defined-standards/specifications/
Introduction
The OPENFLOW specification covers the components and the basic functions of the switch, and the OpenFlow switch protocol to manage an OpenFlow switch from a remote OpenFlow controller.
Openflow Version Details:
Openflow 1.1 Openflow 1.2 Openflow 1.3 Openflow 1.4 Openflow 1.5
Most widley used: 1.3
Switch Components
An OpenFlow Logical Switch consists of one or more flow tables and a group table, which perform packet lookups and forwarding, and one or more OpenFlow channels to an external controller (Figure 1).
- The switch communicates with the controller and the controller manages the switch via the OpenFlow switch protocol.
- Using the OpenFlow switch protocol, the controller can add, update, and delete flow entries in flow tables, both reactively (in response to packets) and proactively.
- Each flow table in the switch contains a set of flow entries; each flow entry consists of match fields, counters, and a set of instructions to apply to matching packets.
- Matching starts at the first flow table and may continue to additional flow tables of the pipeline
- Flow entries match packets in priority order, with the first matching entry in each table being used.
- If a matching entry is found, the instructions associated with the specific flow entry are executed.
- If no match is found in a flow table, the outcome depends on configuration of the table-miss flow entry: for example, the packet may be forwarded to the controllers over the OpenFlow channel, dropped, or may continue to the next flow table
Actions included in instructions describe packet forwarding, packet modification and group table processing.
Flow entries may forward to a port. This is usually a physical port, but it may also be a logical port defined by the switch(such as link aggregation groups, tunnels or loopback interfaces) or a reserved port defined by this specification.
Openflow channel
The OpenFlow channel is the interface that connects each OpenFlow Logical Switch to an OpenFlow controller. Through this interface, the controller configures and manages the switch, receives events from the switch, and sends packets out the switch.
The Control Channel of the switch may support a single OpenFlow channel with a single controller, or multiple OpenFlow channels enabling multiple controllers.
The OpenFlow channel is usually encrypted using TLS, but may be run directly over TCP
Default Port number : 6653
Openflow Flow table
A flow table entry is identified by its match fields and priority: the match fields and priority taken together identify a unique flow entry in a specific flow table.
A flow table consists of flow entries.
Example Flows with MAC Match
Example Flows with IP Match
Example Flows with TCP/UDP Ports Match
match fields: to match against packets. These consist of the ingress port and packet headers, and optionally other pipeline fields such as metadata specified by a previous table
priority: matching precedence of the flow entry.
counters: updated when packets are matched.
instructions: to modify the action set or pipeline processing.
timeouts: maximum amount of time or idle time before flow is expired by the switch.
cookie: opaque data value chosen by the controller. May be used by the controller to filter flow entries affected by flow statistics, flow modification and flow deletion requests. Not used when processing packets.
flags: flags alter the way flow entries are managed, for example the flag OFPFF_SEND_FLOW_REM triggers flow removed messages for that flow entry.
The flow entry that wildcards all match fields (all fields omitted) and has priority equal to 0 is called the table-miss flow entry.
The table-miss flow entry must support at least sending packets to the controller using the CONTROLLER reserved port.
Openflow Matching
On receipt of a packet, an OpenFlow Switch performs the functions shown as below.
The switch starts by performing a table lookup in the first flow table, and based on pipeline processing, may perform table lookups in other flow tables
#### Match Fields
Reference : Page 62 of the specification
Match fields come in two types, header match fields and pipeline match fields.
Header match fields are match fields matching values extracted from the packet headers. Most header match fields map directly to a specific field in the packet header defined by a datapath protocol
All header match fields have different size, prerequisites and masking capability
Pipeline match fields are match fields matching values attached to the packet for pipeline processing and not associated with packet headers, such as META_DATA, TUNNEL_ID. Refer : Page 66.
Prerequisties Example:
If you want to include the SRC IP Address in the match, Prerequisties is ETH_TYPE should be 0X0800. It means, you need to include the ETH_TYPE match also.
Masking example:
You can match the Source IP against with Subnet. Refer page 64 for detailed table.
Instructions
Each flow entry contains a set of instructions that are executed when a packet matches the entry. These instructions result in changes to the packet, action set and/or pipeline processing.
Apply-Actions action(s):
- Applies the specific action(s) immediately, without any change to the Action Set.
- This instruction may be used to modify the packet between two tables or to execute multiple actions of the same type.
- The actions are specified as a list of actions
Clear-Actions:
- Clears all the actions in the action set immediately.
Goto-Table next-table-id:
- Indicates the next table in the processing pipeline. The table-id must be greater than the current table-id.
Write-Actions action(s):
- Merges the specified set of action(s) into the current action set
Meter meter id:
- Direct packet to the specified meter.
Action Set and Actions:
Action set contains set of actions.
Example actions are:
Output port no
Group group id
Drop
Set-Queue queue id
Push-Tag/Pop-Tag ethertype (VLAN, MPLS, PBP)
Set-Field field type value
Change-TTL (IP TTL, MPLS TTL)
#### Flow Removal
Flow entries are removed from flow tables in two ways, either at the request of the controller or via the switch flow expiry mechanism.
Flow expiry:
Each flow entry has an idle_timeout and a hard_timeout associated with it
Example:
Hard_timeout If the hard_timeout field is non-zero, the switch must note the flow entry’s arrival time, as it may need to evict the entry later. A non-zero hard_timeout field causes the flow entry to be removed after the given number of seconds, regardless of how many packets it has matched.
idle_timeout If the idle_timeout field is non-zero, the switch must note the arrival time of the last packet associated with the flow, as it may need to evict the entry later. A non-zero idle_timeout field causes the flow entry to be removed when it has matched no packets in the given number of seconds. The switch must implement flow expiry and remove flow entries from the flow table when one of their timeouts is exceeded.
#### Counters
statistics are maintained by the openflow switch as below,
- Per flow entry
- Per flow table
- Per Switch Port
- Per Queue
- Per Group
- Per Group Bucket
- Per Meter
- Per Meter Band
### Openflow Messages
Three types of messages.
1. Controller to Switch
Controller-to-switch messages are initiated by the controller and used to directly manage or inspect the state of the switch
- Feature Request
- Packet Out
- Modify Flow Table
- Modify Group Table
- Modify Meter Table
- OpenFlow Switch Description Request
- OpenFlow Port Description Request
- Openflow Statistics Request(Flow, Port, Flowtable, Aggregate, Group, Meter, Queue )
- Role Request
- Barrier Request
2. Asynchronous
Asynchronous messages are initiated by the switch and used to update the controller about network events and changes to the switch state
- Packet In
- Flow Removed
3. Symmetric
Symmetric messages are initiated by either the switch or the controller and sent without solicitation.
- Hello Message
- Echo Message
Message transcation - during the Topology Setup
- Hello
- Feature request/Response
- Switch/Port Description Request/Response
- Modify Flow Entry (To install table Miss entry)
- Packet IN (Switch to Controller)
- Packet Out (Controller to Switch)
- Modify Flow Entry (Install a flow)
- Echo
Hello Message:
Hello messages are exchanged between the switch and controller upon connection startup.
Switch sends Openflow Hello Message(includes version number) to the Controller
Controller responds with the Hello Message if version is supported.
Failure Case(Version MisMatch): If different Openflow Version is user between the Controller and Switch, Hello Message will fail.
You will see similar error msg in the controller.
Error:unsupported version 0x1. If possible, set the switch to use one of the versions [3]
Echo Message:
Echo request/reply messages can be sent from either the switch or the controller, and must return an echo reply. They are mainly used to verify the liveness of a controller-switch connection, and may as well be used to measure its latency or bandwidth.(default: 5sec interval)
A. Switch sends Echo Request to the Controller.
B. Controller responds back with Echo Reply.
Features Request/Reply:
The controller may request the identity and the basic capabilities of a switch by sending a features request;
The switch must respond with a features reply that specifies the identity and basic capabilities(datapath ID, buffers, number of tables, statistics) of the switch.
This is commonly performed upon establishment of the OpenFlow channel.
Packet-in:
Transfer the control of a packet to the controller. For all packets forwarded to the CONTROLLER reserved port using a flow entry or the table-miss flow entry, a packet-in event is always sent to controllers
#### Packet-out Message:
These are used by the controller to send packets out of a specified port on the switch, and to forward packets received via Packet-in messages. Packet-out messages must contain a full packet or a buffer ID referencing a packet stored in the switch.
The message must also contain a list of actions to be applied in the order they are specified; an empty list of actions drops the packet.
Modify Flow Entry Message:
Modifications to a flow table from the controller are done with the OFPT_FLOW_MOD message:
To add, remove, modify the flow in the switch, controller using this message.
Controller Sends the Flow Modification message to the switch with this important params (Command, Match, Instruction, action.)
Command: ADD, MODIFY, MODIFY_STRICT, DELETE, DELETE_STRICT
Openflow Ports
Physical ports:
The OpenFlow physical ports are switch defined ports that correspond to a hardware interface of the switch. In the Virtualized environment it represents the virutal interface.
Example: "s1-eth1"
#### Logical ports:
Logical ports are higher level abstractions that may be defined in the switch using non-OpenFlow methods (e.g. link aggregation groups, tunnels, loopback interfaces).
Example: "vxlan0"
#### Reserved ports:
The OpenFlow reserved ports are defined by this specification. They specify generic forwarding actions such as sending to the controller, flooding, or forwarding using non-OpenFlow methods, such as “normal” switch processing. FLOOD, ALL, CONTROLLER, IN PORT, LOCAL, NORMAL,
Example: FLOOD
Important Take aways
1) Openflow version should match between the switch and Controller
2) Our Controller Application(our RYU project/exercise) should process Packet IN (Message), to build the Switching/Routing logic.
3) Our Controller Application(our RYU project/exercise) should use Flow Modifcation message to add/modify/delete the flows in the switch.
4) Our Controller Application(our RYU project/exercise) should use Flow Stats, Port Stats request message to get the statistics(Packets Sent/Received , etc) of the flows, Ports .
7. RYU Controller - Basics
Introduction
Ryu is a component-based software defined networking framework. Ryu provides software components with well defined API that make it easy for developers to create new network management and control applications. Ryu supports various protocols for managing network devices, such as OpenFlow, OVSDB, BGP. About OpenFlow, Ryu supports fully 1.0, 1.2, 1.3, 1.4, 1.5 and Nicira Extensions. All of the code is freely available under the Apache 2.0 license.
How to run RYU applications
run the ryu application:
ryu-manager ryu.app.application-name
Example:
ryu-manager ryu.app.simple_switch_13
In built applications are available in
https://github.com/osrg/ryu/tree/master/ryu/app
Some of the applications are ,
- simple_switch
- simple_monitor
- ofctl_rest
- rest_qos
- rest_firewall
- rest_router
ryu-manager ryu.app.simple_switch_13
Example:
Check the Openflow port status
RYU Manager listens on openflow ports(6653) are in listening state.
netstat -ap | grep 6653
How to stop the ryu controller
How to run your (custom developed) applications.
RYU application is a python script.
Example:
ryu-manager l3_switch.py
How to run your multiple applications.
RYU can run multiple applications in a single initiation.
Example:
ryu-manager ryu.app.simple_switch_13 ryu.app.ofctl_rest
RYU Controller command line options
To know all the available options
ryu-manager --help
To enable the debug logs:
ryu-manager --verbose application_name
To use custom openflow port number
ryu-manager --ofp-tcp-listen-port 6634 application_name
Example:
To use topology discovery
ryu-manager --observe-links application_name
Example:
ryu-manager --observe-links ryu.app.simple_switch_13
Reactive/Proactive Flows
Reactive Flows:
- When the new packet enters in the switch, if it doesnot match on the existing flows, Switch sends it to the controller.
- controller inspect the packet, and build the logic
- install the flow for that session(match) in the switch Packet IN /Packet Out
Proactive Flows:
- OpenFlow controller will install flow tables ahead of time for all traffic matches.
Simple Proactive Hub Application
Install the Openflow flow in the switch which performs FLOOD action, when switch connects to the controller.
Testing
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU hub application
ryu-manager hub.py
- Check the flows
sudo ovs-ofctl -O OpenFlow13 dump-flows s1
- Perform Ping between the hosts in mininet
- Watch the flows again
OpenFlow Applications
Applications are Part of SDN Controller
- Most of the RYU Applications are this category. example , simple_switch application, monitor application.
- To develop this application, we should know the RYU Python API, and RYU Programming guidelines.
- Most of the academic projects will be developed in this type.
Application sits externally, and communicate with SDN Controller thru North bound plugin
- User using NorthBound interfaces(REST API) to add the flows ,
- Packet In /Packet Out will not be considered as the flow control is handled externally by the user or external application.
- No Packet generation capability(Packetout)
Basic Openvswitch Commands
Simple Switch Application (in built)
Simple Switch Application is RYU inbuit basic switching application works in reactive model.
- Install the Table Miss entry to the switch
- When the packet comes to Switch, it matches with Table Miss Entry, then Switch send it to the Controller(PACKET IN message)
- Controller look the src mac of the packet and updates in its db(port to mac mapping)
- Controller look the destination mac of the packet, and decides on the output port .
- Controller send the packet to switch (PACKET OUT message)
- Controller add the flow using (FLOW Modificcation message), here match field is based on MAC address.
Testing
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU simple switch application
ryu-manager ryu.app.simple_switch_13
- Check the switch & flows
Table Miss entry to be present
- Do h1 to h2 ping from mininet prompt
- Check the flows again
- Look the Priority, Match and Action field
Priority:
priority=1
Match:
in_port="s1-eth2",dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01
Action:
output:"s1-eth1"
### Simple L3 Switch
This exercise is same as Simple Switch Application, except Match is based on IP address.
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU l3switch application
ryu-manager l3_switch.py
- Check the switch & flows
- Do h1 to h2 ping from mininet prompt
- Check the flows again
- Look the Priority, Match and Action field
Priority:
priority=1
Match:
ip,nw_src=10.0.0.1,nw_dst=10.0.0.2
Action:
output:"s1-eth2"
Simple L4 Switch
This exercise is same as Simple Switch Application, except Match is based on IP address,IP Protocol, src and dst Port
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU l4switch application
ryu-manager l4_switch.py
Check the switch & flows
Do h1 to h2 ping from mininet prompt
start iperf tcp server in h2
- Run iperf client in h1 connecting to h2
- Check the flows again
- Look the Priority, Match and Action field
Priority:
priority=1
Match:
tcp,nw_src=10.0.0.1,nw_dst=10.0.0.2,tp_src=59010,tp_dst=5001
Action:
output:"s1-eth2"
Simple Switch with flow expiry
This exercise is same as Simple Switch Application with idle_timeout and hard_timeout. So the flow will be removed/expired after certain time.
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU flow timeout application
- Do pingall from mininet prompt
- Check the flows continuously
Look the idle_timeout, hard_timeout value
Check the flows again after 10 secs(idle_timeout time) . Flows will be expired and not available in the switch.
Controller Connection Failure
Openvswitch support two mode of operation upon Controller connection fails A. Standalone Mode B. Secure Mode
A. Standalone mode:
- Openvswitch act like an ordinary MAC-learning switch(traditional switch).
- Openvswitch will take over responsibility for setting up flows (when no message has been received from the controller for three times the inactivity probe interval)
- In the background, Openvswtitch retry connecting to the controller, when it succees it switch it to the openflow mode.
B. Secure Mode:
- In this mode, Openvswitch will try to connect forever. It will not set up flows on its own when the controller connection fails.
How to configure:
you can check the current configuration, using
ovs-vsctl show
To configure:
ovs-vsctl set-fail-mode switch-name standalone ovs-vsctl set-fail-mode switch-name secure
Example:
Demo
- Start the Mininet Topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run the RYU SDN Controller with flowtimeout application.
- Check the Switch mode
- Do continuous ping from h1 to h2
Stop the Controller
After flows are expired, the ping stopped. No data traffic will be passed in the switch.
Start the controller again.
Flows will be installed, and Ping will continue
Configure the switch in "standalone mode"
Stop the controller again
After the flows are expired, the switch will move to standalone mode and continue to pass the traffic.
8. RYU Programming - Basics
Ryu applications are just Python scripts so you can save the file as (.py) on any location.
Components
ryu-manager :
- main executable
ryu.base.app_manager:
- The central management of Ryu applications
- Load Ryu applications
- Provide contexts to Ryu applications
ryu.ofproto:
- OpenFlow wire protocol encoder and decoder:
ryu.controller:
- openflow controller implementation
- generates openflow events
ryu.packet:
- all packet parsing libraries
Events:
RYU Application works based on Events. RYU Controller emits the events for the Openflow Messages received. This can be handled by the RYU Applicaltions.
Example Events:
ofp_event.EventOFPSwitchFeatures ofp_event.EventOFPPacketIn ofp_event.EventOFPFlowStatsReply
https://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html
Simple Switch application is a base application to refer. https://github.com/osrg/ryu/blob/master/ryu/app/simple_switch_13.py
Closer look on Simple_Switch_13 application
Lets have quick Recap on the OpenFlow Message transcations between Controller and Switch.
- Hello Message
- Feature Request/Response Message
- Flow Modification message to install Table Miss Entry
- Packet In Message
- Packet Out Message
- Flow Modification Message to Install the Flows
we can classify the program in few important parts.
1.Import the base classes / library
- Application Class (derived from app_manager)
- Important openflow events handled
Features_Response_Received
PacketIn_Message_Received
we can handle this event, in our application as below,
In the switch_features_handler event, we add the TABLE MISS Entry . So we get the packet in messages.
In the packet_in_handler event, we process the PACKETs and parse the src_mac and dst_mac address and build the switching logic and install the flow.
#### Inserting(Adding) a flow
Flow table consists of Match, Actions and Counters.
A. Create a Match
Reference:
https://github.com/osrg/ryu/blob/master/ryu/ofproto/ofproto_v1_2_parser.py#L3403
This match is with no match fields. it means matching all the packets.
This matches with in_port, eth_dst and eth_src field.
B. Create a Actions
https://github.com/osrg/ryu/blob/master/ryu/ofproto/ofproto_v1_2_parser.py#L1252
Below action is send it to CONTROLLER(Reserved port).
Below action , send it to port number 1.
C. Create a Instruction list with Actions
D. Send OFP Flow Modifiation meassage for creating a new flow
Most of the parameter are default. table_id, timeouts, cookies etc.
In Below example, explicitly specify tableid, timeouts.
9. Developing Switching Applications
we use simple_switch_13 application as base application, and will build hub, L3, L4 Match applications
HUB Application
Logic
Create a Flow, all Matches with FLOOD Action
No need of TABLE MISS Entry.
So, we can simply modify the TABLE MISS Entry action as FLOOD to achieve the HUB Operations.
Code changes
In the Switch Features handler, modify the action as FLOOD.
We will never get Packet_in event , So we can remove those routines.
Save this file as hub.py
Demo
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU hub application
- Check the openvswitch flows
- do pingall from mininet.
Switch Application With L3 Match
Logic
simple_switch_13 application as a base application and switch learning process is same
But Flow will be based on Layer3 Match (src ip and destination ip) instead of src_mac and dst_mac
Code changes
- include the IP library
- Populate the Match based on IP.
- Check the packet is IP Packet, then decode the srcip and dstip from the packet header
- Populate the Match based on srcip and dstip.
Demo
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU hub application
do pingall from mininet.
Check the openvswitch flows
Switch Application With L4 Match
Logic
simple_switch_13 application as a base application and switch learning process is same
But Flow will be based on Layer4 Match (src ip and destination ip, protocol and port number) instead of src_mac and dst_mac
- In the ethernet packet, check the ether frame type field is IP.
- if it is IP, load the IP Packet from the packet, extract the srcip , and dst ip from IP Packet.
- Check the IP Protocol(ICMP or TCP or UDP)
- If it is ICMP Prepare the openflow match with IP Src, IP dst and Protocol.
- If it is TCP, extract the tcp src port and tcp dst port fied Prepare the openflow match with IP Src, IP dst and Protocol, TCP Src Port and TCP dst port..
- If it is UDP Extract the udp src port and tcp dst port fied Prepare the openflow match with IP src, IP dst , protcol, udp src and udp dst port.
Code changes
- include the header
- Populate the Match
Demo
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU hub application
do pingall from mininet.
Check the openvswitch flows
Flow Timeout
Idle Timeout:
If the flow is Idle(no packets hitting this flow) for the specified time(Idle Time), the flow will be expired.
Hard Timeout:
Flow entry must be expired in the specified number of seconds regardless of whether or not packets are hitting the entry
In simple_switch.py, the default timeout values(for idle and hard) are not set(0). it means, the flows are permanent. it will never expiry.
Code changes
In the add_flow function, include idle, hard parameters with default value as 0.
OFPFlowMod API include the idle_timeout,hard_timeout parameters.
- Call the add_flow function with idle, hard value
Demo
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU hub application
do pingall from mininet.
Check the openvswitch flows
verify the timeout values in the flow,
- Check the flows again after the timeout seconds.
10. Statistics Collection
Openflow protocol provides extensive statistics, such as,
- flow statistics
- flow aggregate statistics
- port statistics
- group table statistics
- meter statistics
User can collect these statistics from the openflow switch and use it(its used for many applications)
User needs to send the statistics request meassge(Example: OpenFlow FlowStatistics Request Message). Switch reply with statistics respone message.
In this tutorial, we are going to write a RYU Code to display the statistics.
RYU Thread API
RYU comes with inbuilt thread implementation(hub library.)
Import the library
We will write a piece of code, which will be executed in separate thread forever.
Note: its a continuous run, so we use hub.sleep() to sleep for a time.
To initiate a thread
Demo
ryu-manager thread.py
Example:
Flow Statistcs
Measure the flows statistics or utilization in regular interval(10second) and print it.
Logic
- Use Ryu Thread(HUB) mechanism,
- In the Thread, Send Openflow Flow Statistics Request message at regular interval
- Flow Statistics Response will be received as event, and display the bytes & packets counter values.
#### Coding
- Use Simple Switch application as base application
- we require datapaths object of all the switches for generating the stats request message. hence we store the datapaths in the dictionary.
In the init routine, we declare it.
In the switch features handler function, we store the the datapath object in the datapaths dictionary.
- Include RYU Thread library
- Start the thread in the init routine
Here thread function name is monitor.
- Thread function
The thread function to be placed in side the RYU manager application class.
In the thread function, we process the datapaths(switches) dictionary, and generate the flowstats request message(without any match filter). It means we query the stats of all the flows in the switch.
Refer:
- Flow Stats Response handling routine.
Reference:
#### Demo
- start the mininet single topology
- run our application.
- ping h1 to h2 in mininet
- In the ryu console, we can see the output
Aggregate Flow Stats
Measure Total number flows in regular interval(10second) and print it.
Logic
- Use Ryu Thread(HUB) mechanism,
- In the Thread, Send Openflow Aggregate Flow Statistics Request message at regular interval
- Aggregate Flow Statistics Response will be received as event, and display the bytes & packets counter values.
#### Coding same as flow statistics example for thread stuff. But we send Aggregate flow stats request.
Reference:
Aggregate Flow Stats Response handling routine.
Reference:
demo
- start the mininet single topology
- run our application.
- ping h1 to h2 in mininet
- In the ryu console, we can see the output
Result:
Port Statistics
This is similar to previous two exercises
we should use port stats request message.
For Port Stats response,
Demo same procedure as last two exercises
11. Configuration File
At various sceanarios, user need to provide input to the Application instead of hardcoded in the program. For example, user can provide INTERVAL interval in the statistics applications.
RYU supports configuration file input, which will be parsed by the RYU Application and we can use it as a variable.
Configuration File
step1:
Enter the configuration in a file as below format,
cat params.conf
Here we specificed the INTERVAL as 10.
step2:
In the Ryu application,
Include the library for configuration apis
Read the Configuration in the init routine of the application
step3:
When you run the ryu application, you should use --config-file filename options as below,
ryu-manager --config-file params.conf flow_stats_param.py
Demo
Now we updated the flow statistics program (flow_stats.py) with configurable INTERVAL parameter.
Repeat the same demo flow statistics procedure.
12. Group Table
Please refer the group table theory/concepts from PART2 . In this guide, we are going to see, programming methods/api for for group table.
Sniffer Program
Make h2 as Sniffer machine. it will sniff all the packets passing via S2.
Logic
Group table1(Group Table ID 50):
Create a Group table with TYPE=ALL(it means, copy a packet for each bucket. and each bucket will be processed). create two buckets. one bucket will send the packet to Port3, another bucket will send the packet to Port1
Group table2(Group ID 51):
Create a Group table with TYPE=ALL(it means, copy a packet for each bucket. and each bucket will be processed). create two buckets. one bucket will send the packet to Port2, another bucket will send the packet to Port1
Proactively We create group tables and flows in S2.
Coding
Use simple_switch_13 as base code
- Creat a group table create function.
Here we use OFPGroupMod API for creation groups. refer the API for more details https://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPGroupMod
- In Switch features handler function, call the Group table creation function and add flows for switch S2,
Demo
- run the topology in mininiet
- Run the ryu controller application(simple switch and ofctl)
- Do pingall from mininiet
- Check the flows of switch s2
Loadbalancer
Forward the packet to 1 bucket(out of N buckets) and process it. (Load Balancer)
Logic
In Switch S1 ,
Create a Group table with TYPE=SELECT (it means, For each bucket, a bucket will be selected (based on weight - vendor implementation ). and the selected bucket will be processed).
create two buckets. one bucket will send the packet to S2 Port, another bucket will send the packet to S3 Port
In Switch S5 ,
Create a Group table with TYPE=SELECT (it means, For each bucket, a bucket will be selected (based on weight - vendor implementation ). and the selected bucket will be processed).
create two buckets. one bucket will send the packet to S4 Port, another bucket will send the packet to S3 Port
Proactively We create group tables and flows in S1 and S5.
Coding
Use simple_switch_13 as base code
- Creat a group table create function.
Here we use OFPGroupMod API for creation groups. refer the API for more details https://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPGroupMod
- In Switch features handler function, call the Group table creation function and add flows for switch S1 and S5,
Demo
- run the topology in mininiet
- Add the static ARP Entry in the mininiet hosts
- Run the ryu manager
- Testing
Verify the flows
run iperf test between h1 and h5
Check the flows and groups.
Further experiments:
- Multipath load balancing with specified percentage
- Dynamically do the load balancing depends on the traffic condition.
- Failover
References
- openflow 1.3 specification documemnt, 5.6 Group table
- http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html
- https://www.quora.com/Why-dose-the-Openflow-protocol-exist-the-group-table-And-what-the-relationship-between-pipeline-and-group-table
- http://www.muzixing.com/pages/2014/11/07/load-balancemultipath-application-on-ryu.html
13. Packet Generation
RYU comes with packent library (consists of plenty of protocols), we can use this library to parse the packets or generate the packets.
There are many usecase around this.
Packet Parsing Capbility
We can use the packet library to parse the PACKET IN Message and identify which application and use it.
- Include the relevant packet library
- In the Packet In handler,
Get the Packet Handler object
Now we can get the Protocol headers from the pkt
To get the ethernet header
To Get the IP Header
To Get the TCP header
To get the UDP header
Further we can get the Protocol header details, by processing it
RYU can handle these many protocols
https://github.com/osrg/ryu/tree/master/ryu/lib/packet
Packet Generation Capbility
In SDN, SDN Controller can generate a packet and send it. There are many usecases/applications require this capability.
Router SDN Controller needs to have ARP Request & Response capability for neighbour discovery
Proxy Application (ARP Proxy, DNS Proxy) Proxy application need to handle the request of the specific proxy application protocol(such as DNS, ARP etc) and respond it.
Simple ARP Proxy application
Objective This application answers the ARP requests(instead of forwarding the ARP broadcasts to all hosts)
This Application act as ARP Proxy. It captures the ARP Packets, builds the ARP response and send it to the Src.
Logic
- MAC with IP Table will be hardcoded in the code.
- In the Packet IN handler, check the packet is ARP Packet.
- If it is ARP Packet,
- In the ARP Request Packet, decode the destination IP from ARP header
- Get the MAC address of the equivalent IP address
- Build the ARP Response packet
- Send it to the Received PORT.
- If not ARP, normal switching routine.
Coding
- include the lib
- define your table with MAC address and IP Address.(ARP Table)
- Write your arp proxy function
- In the packet handler function, if it is arp packet, call the arp_proxy function.
Demo
- Run Mininet topology
sudo mn --controller=remote,ip=127.0.0.1 --mac -i 10.1.1.0/24 --switch=ovsk,protocols=OpenFlow13 --topo=single,4
- Run RYU hub application
- Check the openvswitch flows
- start the tcpdump capture in h2
- do ping h1 to h2 from mininet
- Check the tcpdump traces in h2 you will not the ARP Request, Controller respond with ARP Reply.
Further Experiments
- Implement DNS Proxy Application
- Implement Simple Gateway / router Application
14. Topology Discovery
RYU has Topology discovery mechnism. RYU uses LLDP(Link Layer Discovery Protocol) to discover the switches and links. Topology discovery feature will be enabled with "--observe-links" option.
Topology discovery feature is used in many applications such as identify the shortest path, avoid loops, multipath with load balancing etc.
How it works
Switch & Link Discovery:
- RYU Controller generates LLDP Packet(datapath id, port number) from each switch and each port number.
- LLDP Packet reaches the other end of the link (its another switch port).
- This packet will send it to the controller
- Controller decodes the packet and learn the Switch, and Link information from the LLDP Packet (sender switch details(datapath ID, Port number) and received switch details((datapath ID, Port number)) )
Host discovery:
Host discovery is based on the incoming packet. Usually the host machines are keep sending some broadcast/multicast packets(some services will trigger this). RYU Controller uses these packets to discover the hosts.
Coding
Logic:
Topology discovery process may take few seconds to complete it . So we use RYU thread and print the topology information after 10seconds. We assume within 10 seconds, the topology discovery process will be completed.
- Include the header
- Initiate a thread
- Printing the topology discovery information
we use three APIs get_switch, get_link, get_host . These api provides the discovered switch,link and host details in the list of objects.
This below line, we are processing the switch list, and get only switch dp id.
Simiar to other link and host.
Demo
- Run Mininet Linear Topology
Start the Wireshark Capture with loopback interface
Run ryu controller with "--observe-links" options
- Topology information will be printed in the RYU Console.
- Analyze the Wireshark traces(LLDP Packets)
References
- https://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
- https://vlkan.com/blog/post/2013/08/06/sdn-discovery/
- https://github.com/Ehsan70/RyuApps/blob/master/TopoDiscoveryInRyu.md
15. Multicontrollers
Problem Statement
Controller failure in SDN Network is major failure affects the entire network topology
Various reasons for controller failure - security threats, hardware /software issues, manual errors etc.
Using Single Controller in SDN Network is high risk, high possibility for failure, not scalable and fault tolerant.
### Demo - Single Controller
Running Mininet topology with Linear topology.
sudo mn --controller=remote,ip=127.0.0.1 --mac -i 10.1.1.0/24 --switch=ovsk,protocols=OpenFlow13 --topo=single,4Running a ryu controller with simple switch application( idle timeout/hard timeout to 30seconds)
Pingall.
Stop the controller
Check the flows
Observation: Once the controller is stopped, topology works till the flows are timeout(hard) after that, the entire topology datapath is not working. hosts cannot reach other hosts.
Its a single point failure.
Cluster of SDN Controllers:
Openflow specification supports the Multiple controllers environment. User can configure the multiple controllers in the switch.
Controller Roles
#### Equal Role
It means, all the controllers configured in the switch have full control to update/modify the flows.
Switch must send the PACKET IN Message to all the Controllers. Also switch process the PACKET OUT, FLOW UPDATES etc from all the controllers.
#### Master Role
It means, MASTER controller will be responsible for managing the switch openflow dataplane. Switch will send the control messages to only MASTER controller.
#### Slave Role
Slave plays backup role for MASTER. it also receives the HELLO and KEEPALIVE Message. But it cannot send and receive the Control message.
4.Openflow ROLE Change Message:
ROLE_REQUEST and RESPONSE:
When the controller comes up, it will send the ROLE REQUEST with ROLE MASTER, other controller should send a role as SLAVE. Switch will communicate with MASTER.
Demo - Equal role
- controller1
- controller2
- Mininet topology
- Start the wireshark capture for traces
- pingall
Note : we can see the packet in comes from both controller
Demo- Master/Slave Role
Here one controller going to act as Master Role, another controller going to act as SLAVE or BACKUP role.
- Start the wireshark capture for traces in loopback interface
- Mininet topology
- start the master controller
- start the backup controller
- Check the traces in controller terminals. you can see only MASTER terminal you can see packet in traces.
- pingall
only MASTER Controller manages the switches
- Analyze the ROLE Messages in the Wireshark traces.
Data Synchronization
In Multicontroller environement(specifically Master/slave), data(intelligence built by the controller. For example mac_to_port structure) needs to be synchronized across the controller.
There are many mechnisms available such as DB, InMemoryDB, Message Brokers etc.
Further experiments
- Use InmemoryDB or MessageBroker for DataSynchronization
- Implement Master Election Algorithm/ Failure Detection /Autofailover
- Distributed Master/Slaves
16. REST API
In this guide, we will see how we can include REST API support in our application. So far, we use only application class(app_manager.RyuApp) For REST API support, We have to define two class in the application.
application (app_manager.RyuApp)
- Our default code
- REST API endpoints declaration
Controller (ControllerBase) - Here we need to implement the REST API handling function.
Sample Program
In this exercise, included dummy REST API which returns hardcoded value.
- Include the WSGI library.
- In the Application class, include wsgi(WebServer) context
defines the controller name, mapper class
- declare the REST API
Here we declare the REST API endpoint and methods.
- specify which controller it connects .
- which function will be triggererd
- Define the controller class
Here we defined the api functions.
Demo As its a dummy application, we dont require mininet
- run the ryu application
- GET Request to the API
References
https://osrg.github.io/ryu-book/en/html/rest_api.html
17. Traffic Tests - Part1
Usually we need to perform various traffic tests between the hosts to test our network topology & SDN application performance.
Some of the test includes:
TCP Tests between two hosts
UDP Tests
UDP Tests with different Packet size (64 bytes, 1024 bytes etc), different packet rate (50 pkts/s, 100 pkts/s etc)
Variable Traffic rate (10Pkts/s for first 60s, then 100Pkts/s for rest of the test )
Multiple/Parallel Streams/Sessions
VoIP Traffic Test
Video Streaming mp4 video file will be used as video source. and will generate the video stream using VLC, and will be received by client using VLC Video Player.
TCP Tests
IPERF is widely accepted traffic generation tool to perform TCP Tests.
- TCP tests generally used for measure the bandwidth.
- Latency, Jitter, Packet loss cannot be measured using TCP Tests.
For all our traffic tests, we will use Simple Topology and l4 switch application.
- Create the topology
- Run the RYU Controller l4 switch applicaion.
- In mininet shell, do ping h1 to h2.
4.check the flows
- understand the Host & Switch Port numbers.
- To check the switch statistics
Now all set to run our traffic tests.
#### A. Traffic test from h1 to h4
Objective: Generate TCP Traffic from h1 to h4. (Measure bandwidth from h1 to h4)
h1 is sender.
h4 is receiver.
- Start IPERF Server in h4
- Start the IPERF Client in h1 and connecting to h4
- Analyze the results by flows
we observe traffic in both directions.
h1 to h4 traffc is very high (in Gbps). This is data traffic. h4 to h1 traffic is very less. This is TCP Acknowledge traffic.
- Analyze the results by ports.
h1 --------port1, port4--------h4
Forward traffic:
- h1 transimits. port1 receives.
- port4 transmits, h4 receives.
Acknowlege:
- h4 transmits. port4 receives.
- port1 transmits. h1 receives.
#### B. Bidirectional Traffic test h1 to h4(sequentially).
- Start IPERF Server in h4
- Start the IPERF Client in h1 and connecting to h4
Its sequential test , once h1 to h4 traffic test is completed it will start h4 to h1 traffic test.
#### C. Bidirectional Traffic test h1 to h4(parallel).
- Start IPERF Server in h4
- Start the IPERF Client in h1 and connecting to h4
Its parallel test , both direction h1 to h4 as well h4 to h1 traffic tests started.
#### D. Traffic test from h1 to h4 with Multiple Sessions.
- Start IPERF Server in h4
- Start the IPERF Client in h1 and connecting to h4
UDP Tests with IPERF
UDP Tests are quite flexible in the nature of playing around packet sizes(64 bytes) and number of packets(10 Packets/s) you want to send. It means, user can control the bandwidth of UDP Traffic.
- Bandwidth, Latency, Jitter, Packet loss can be measured using UDP Tests.
IPERF doesnot provide provide much flexibility in UDP Tests.
- Start IPERF UDP Server in h4
- Start the IPERF Client in h1 and connecting to h4 and generate bandwidth of 10Mbsp
### UDP Tests with MGEN
Multi-Generator (MGEN) is open source traffic gen software
https://downloads.pf.itd.nrl.navy.mil/docs/mgen/mgen.html
Some important features
- variable packet rate
- pattern(Periodic, possion, burst, jitter)
- logs
- scriptable
It doesnot give test report (similar to iperf). we need to process the logs and prepare it.
Installation
A. Simple MGEN UDP Test (Variable Packet rate)
Objective:
we want to generate 10 packets per second for first 0th to 100 seconds. then will send 100 packets per secondfor 100th to 200 seconds. packet size is 1024 bytes.
receive.mgn
send.mgn
How to run mgen:
The default/minimum syntax is below,
mgen input script name
Testing
- Start MGEN Receiver in h3
- Start the MGEN sender in h1
Video Stream Traffic Testing
we use VLC media player(https://www.videolan.org/index.html) for Video Streaming testing.
installation procedure
Testing
- Create the topology
- Run the RYU Controller l4 switch applicaion.
- Download the sample video from internet (or use your own video file)
- h4 is a Video receiver. Start the video receiver in h4 xterm shell
- h1 is video sender. Start the video streaming sender in h1 xterm shell
VOIP Tests
VOIP Traffic is UDP Stream. This can be simulated thru IPERF UDP Tests.
Objective 1. Test the single Voip call 64Kbps 2. Test parallel voip calls
Testing
- Create the topology
- Run the RYU Controller l4 switch applicaion.
A. Single 64Kbps VOICE CALL Test
start the 64Kbps VOIP Traffic Test between h1 to h4 for 60 seconds ,and vice versa.
1) Run the IPERF UDP server in h4
In mininet CLI
Here we are starting udp server, and setting the TOS field to 184
2) Run the IPERF UDP Client in h1
In mininet CLI
B. Multiple Parallel calls VOIP calls test
1) Run the IPERF UDP server in h4
2) Run the IPERF UDP Client in h1
References
- http://wiki.innovaphone.com/index.php?title=Howto:Network_VoIP_Readiness_Test
- https://www.videolan.org/index.html
18. Traffic Tests with DITG
D-ITG (Distributed Internet Traffic Generator) is a platform capable to produce traffic at packet level accurately replicating appropriate stochastic processes for both IDT (Inter Departure Time) and PS (Packet Size) random variables (exponential, uniform, cauchy, normal, pareto, ...).
D-ITG supports both IPv4 and IPv6 traffic generation and it is capable to generate traffic at network, transport, and application layer.
Once installed, Quick verification
Quick Start
ITGRecv command for receiver
ITGSend command for sender
ITGSend/Recv generate the logs. which needs to be ananlzed by ITGDec command to see the result.
UDP
- start the ryu l4_switch app
- run the mininet topology
- start the receiver (or server) on h2
Here the log file is stored in /tmp/receiver.log, which can be decoded via ITGDec.
- start the sender
The options are explained below,
- verify the flows:
You can observe 1 UDP flows and 2 TCP flows(server port 9000). Those TCP flows are used for communicating between ITGSend and ITGRecv for control information.
- To Check the result
The result contain two parts. First part is flow specific,
we ran only one UDP flow, this is mapped with FLOW Number. if we have multiple flows, we can see each flow result.
Second Part is , as a Whole receiver summary.
- Stop the ITGRecv on h2
UDP with three flows(Multiflow mode).
Syntax is below
- Create a script file /tmp/send.sh
Here we generate 3 flows
1st flow generates 30 pkts/per second, with packet size(payload) 100 bytes for 15 seconds
2nd flow generates 20 pkts/per second, with packet size(payload) 500 bytes for 20 seconds
3rd flow generates 10 pkts/per second, with packet size(payload) 1024 bytes for 25 seconds
- start the receiver (or server) on h2
Here the log file is stored in /tmp/receiver.log, which can be decoded via ITGDec.
- start the sender
- verify the flows:
you can see 3 UDP flows and 2 TCP Flows (control channel)
stop the receiver in h2
result verification
we see 3 flows, each flow represents the one which we sent.
TCP Test
DITG TCP Test is more powerful, we can configure the Packet Size, Number of packets/s etc.
- start the receiver (or server) on h2
- start the sender
- check the logs as above test.
Packet distribution (Rate & Size)
Inter-departure time options (Time factor)
Constant distribution
-C rate Constant
Uniform distribution
-U min_rate max_rate Uniform distribution.
Poisson distribution
-O mean Poisson distribution.
Packet size variation
-c pkt_size Constant (default: 512 bytes).
-u min_pkt_size max_pkt_size Uniform distribution.
-o mean Poisson distribution.
VOIP,Telnet,DNS
For VOIP, Telnet, DNS Applications, Receiver method will be same as above examples. only sender option will change as below
- VOIP
- Telnet
- DNS
- FTP
Read payload from file
udp
tcp
Video streaming
- receiver
- Sender
Script file (/tmp/send.sh)
Option details are below -C 24 pkts/second -n 27791 6254 (normal distribution options - packet size) -t 720000 (test time 720s) -m rttm (meter round-trip time meter) -sp 10101 srcport -rp 10001 receiver port -H NAT Traversal
19. References
- https://www.opennetworking.org/sdn-definition/
- https://en.wikipedia.org/wiki/Software-defined_networking
- https://www.sdxcentral.com/sdn-nfv-use-cases/
- https://github.com/mininet/mininet/wiki/Introduction-to-Mininet
- https://github.com/mininet/mininet/tree/master/examples
- http://mininet.org/api/annotated.html
- https://kiranvemuri.info/dynamic-topology-changes-in-mininet-advanced-users-5c452f7f302a
- https://stackoverflow.com/questions/43070043/mininet-wifi-custom-topologyhttps://stackoverflow.com/questions/43070043/mininet-wifi-custom-topology
- http://mininet.org/walkthrough/
- https://github.com/PrincetonUniversity/Coursera-SDN/tree/master/assignments/mininet-topology
- https://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/
- https://ryu.readthedocs.io/en/latest/writing_ryu_app.html
OLD Deleted Contents, keeping it for refernece
Install in ubuntu 18.04
Setup the SDN Test environment to practice Openflow usecases with RYU SDN Controller.
Tools to be installed:
| OS | Ubuntu 18.04 Desktop |
|---|---|
| Test Bed | Mininet |
| Controller | RYU |
| Switch | Openvswitch |
| Packet Capture | Wireshark |
| Traffic Generator | IPerf |
Installation
Requirements:
OS: Ubuntu 18.04.x
CPU: 2 Cores +
RAM: 4GB +
HDD: 15GB+
If you are using Windows or other OS, you can install Ubuntu 18.04 as a Virtual Machine(VM) using Virtual Box .
You can download the ISO installer from the below link,
https://www.ubuntu.com/download/desktop
As first step, please run this command.
Once we installed the above packages, python 2.7 and relavent dependents are installed properly.
To check the python version:
python --version
Example:
At the time of writing, Ubuntu 18.04 official repository has the following tools versions
RYU will be installed using PIP.
a. Openvswitch Installation
sudo apt-get install openvswitch-switch
To verify :
ovs-vsctl --version
Example:
b. Wireshark Installation
sudo apt-get install wireshark
To verify :
wireshark --version
c. Traffic Test Tools installation
IPERF:
sudo apt-get install iperf
CURL:
sudo apt-get install curl
HPING3:
sudo apt-get install hping3
Apache Bench:
sudo apt-get install apache2-utils
To verify :
iperf --version
d. RYU installation
sudo pip install ryu
To verify :
ryu-manager --version
Example:
Note: Make sure you do with "sudo pip install ryu" . ryu package will install ryu-manager binary in /usr/local/bin folder. Hence installation requires sudo access.
e. Mininet Installation
sudo apt-get install mininet
To verify :
mn --version
Log: